Systems and methods for governing content rendering, protection, and management applications

ABSTRACT

System and methods are disclosed for governing digital rights management systems and other applications through the use of supervisory governance applications and keying mechanisms. Governance is provided by enabling the supervisory applications to revoke access keys and/or to block certain file system calls, thus preventing governed applications from accessing protected electronic content.

RELATED APPLICATIONS

This application is a continuation of application Ser. No. 09/874,744,filed on Jun. 4, 2001, and claims the benefit of priority from U.S.Provisional Patent Application No. 60/209,454, entitled “Systems andMethods for Governing Content Rendering, Protection, and ManagementApplications,” filed Jun. 4, 2000, all of which are incorporated hereinby reference.

COPYRIGHT AUTHORIZATION

A portion of the disclosure of this patent document contains materialwhich is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by anyone of the patent documentor the patent disclosure, as it appears in the Patent and TrademarkOffice patent file or records, but otherwise reserves all copyrightrights whatsoever.

FIELD OF THE INVENTION

The present invention relates generally to the management of electroniccontent. More specifically, systems and methods are disclosed forgoverning and managing content-rendering applications and contentprotection and management mechanisms.

BACKGROUND OF THE INVENTION

Advances in electronic communications, storage, and processingtechnology have led to an increasing demand for digital content. Today,large quantities of information can be readily encoded and stored oncompact and easily-transportable media, and can be conveniently accessedusing high-speed connections to networks such as the Internet, or viawireless communication networks such as W-LAN, W-WAN, and cellular.

However, despite the demand for digital content, and the availability oftechnology that enables its efficient creation and distribution, thethreat of piracy has kept the market for digital goods from reaching itsfull potential, for while one of the great advantages of digitaltechnology is that it enables information to be perfectly reproduced atlittle cost, this is also a great threat to the rights and interests ofartists, content producers, businesses, and other copyright holders whooften expend substantial amounts of time and money to create originalworks. As a result, content owners are often reluctant to distributetheir works in electronic form—or are forced to distribute their worksat inflated (or deflated) prices to account for piracy—thus limiting theefficiency and proliferation of the market for digital goods, both interms of the selection of material that is available and the means bywhich that material is distributed.

While increasing attention has been paid to the development of digitalrights management (DRM) mechanisms to address the problems describedabove, the large number of competing—and typically incompatible—rightsmanagement systems have created interoperability and security problemsof their own. As a result, content owners are often reluctant to entrusttheir content to any of the array of content management mechanisms andcontent-rendering applications that presently exist in the marketplace.

SUMMARY OF THE INVENTION

The present invention provides systems and methods for enabling contentowners, industry organizations, and other interested parties tosupervise or govern the application programs, devices, and rightsmanagement systems that are used to render, protect, or otherwise accessor use electronic content. It should be appreciated that the presentinvention can be implemented in numerous ways, including as a process,an apparatus, a system, a device, a method, a computer readable medium,or a combination thereof. Several inventive embodiments are describedbelow.

In one embodiment a supervisory management system is disclosed. A secureprocessing application acts as the supervisor of a second application.The secure processing application is used to access protected digitalinformation that is stored in a secure electronic container. The secureprocessing application extracts secret information—such as an access keyor a portion of an access key—that is needed by the second applicationto access protected content. Revocation of the second application'sauthorization to process protected content can be accomplished byrevoking access to the secure container through the secure processingapplication. In one embodiment, the second application is a digitalrights management system that is operable to manage the use of contentto which the supervisory management system has granted access. Thecontent may consist of encrypted content and rules that govern thecontent's use. In this embodiment, the second application is operable toensure that the content is used in accordance with the rules. If it isdetermined that the second application is not adequately enforcing therules, the supervisory management system can revoke the secondapplication's ability to access the content and/or the secondapplication's ability to grant access to the content.

In another embodiment, a governance system is established by using afirst application to act as a supervisory digital rights managementssystem that controls a second application. The second application ismanaged or controlled by linking with the first application. The firstapplication filters or mediates the calls from the second application tocertain native platform services. When the second application makescalls to its native platform prior to opening a file, the request isfiltered through the first application, which applies rules and/orcredential checks to regulate or manage the files to which the secondapplication is granted access.

In yet another embodiment a method is disclosed for utilizing onedigital rights management application to govern the operation of anotherdigital rights management application. A control application receives arequest to access electronic content from the governed application. Thecontrol application also receives a keyshare from the governedapplication. The control application requests another keyshare from thegoverning digital rights management application. If certain conditionsare satisfied, the governing application supplies its keyshare to thecontrol application. The control application uses the two keyshares toretrieve information that is needed by the governed application toaccess the requested content. The control application retrieves theprotected content and provides it to the governed application (orprovides the information needed by the governed application to accessthe protected content).

In another illustrative embodiment, a system for controlling access toelectronic content is described. The system includes a first applicationprogram that is configured to request access to protected electroniccontent. The first application manages the electronic content inaccordance with rules that are associated therewith. In addition, asecond application program is provided for releasing the protectedelectronic content to the first application program in response to thefirst application's request. The second application is capable ofreceiving information from a third party or external source thatindicates whether or not the second application should grant access tothe protected electronic content to the first application.

In another embodiment, a method is described for controlling anapplication's access to electronic content. When the applicationattempts to retrieve electronic content by invoking standard file systemcalls, these calls are routed to a special conformance library whichinvokes a governance engine. The governance engine is designed toperform integrity checks on the application program to detect impropermodifications. If the application program has been improperly modified,the governance engine will deny access to the content by blocking thefile system calls. Furthermore, the conformance library will alsodetermine if the application program has received affirmativeauthorization to access electronic content. If no authorization isdetected, then the application program will be denied access to theelectronic content. Otherwise, the application is allowed to access theelectronic content.

These and other features and advantages of the present invention will bepresented in more detail in the following detailed description and theaccompanying figures which illustrate by way of example the principlesof the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will be readily understood by the followingdetailed description in conjunction with the accompanying drawings,wherein like reference numerals designate like structural elements, andin which:

FIG. 1 illustrates a system for governing the operation of other digitalrights management systems using a supervisory digital rights managementsystem.

FIG. 2 illustrates the use of a secure processing application to managea second digital rights management application.

FIG. 3A illustrates a conventional mechanism for accessing electroniccontent.

FIG. 3B illustrates a system for governing a content rendering and/ormanagement application in accordance with an embodiment of the presentinvention.

FIG. 3C illustrates a system for governing a content rendering and/ormanagement application in accordance with another embodiment of thepresent invention.

FIG. 4 illustrates a method for governing content rendering applicationsand digital rights management systems.

DETAILED DESCRIPTION

A detailed description of the invention is provided below. While theinvention is described in conjunction with several embodiments, itshould be understood that the invention is not limited to any oneembodiment. Instead, the scope of the invention is defined only by theappended claims, and encompasses numerous alternatives, modifications,and equivalents. While numerous specific details are set forth in thefollowing description in order to provide a thorough understanding ofthe present invention, the present invention may be practiced withoutsome or all of these details. Moreover, for the purpose of clarity,certain technical material that is known in the art related to theinvention has not been described in detail in order to avoidunnecessarily obscuring the present invention. For example, referencewill be made to a number of terms and concepts that are well-known inthe field of cryptography. Background information on cryptography can befound, for example, in Menezes et al., Handbook of Applied Cryptography(CRC Press 1996)(“Menezes”), and Schneier, Applied Cryptography, 2d ed.(John Wiley & Sons 1995).

Governance Via a Secure Processing Application

In one embodiment a secure processing application (e.g., a supervisorydigital rights management system) is provided to govern the operation ofa second application. The second application may include other digitalrights management systems or other applications. For example, the secondapplication might comprise a music player, video streaming application,text reader, or the like. The supervisory DRM system has the ability torevoke the second application's ability to access information that thesecond application needs in order to grant access to content. Thecontent may be deployed in a globally interoperable fashion or in anon-interoperable fashion.

Referring to FIG. 1, a secure processing application 100 is installed ona PC client, computing device, and/or commerce service 101. As describedin more detail below, the secure processing application 100 acts as thesupervisor of a second application 103 which may also be installed onsystem 101. Alternatively, application 100 may be installed on acomputer system that is remote from the system on which application 103is installed.

As shown in FIG. 1, secure processing application 100 preferablyincludes (or is able to establish) a protected processing environment110 and a protected database 104. The secure processing application 100is preferably able to process protected data (e.g., cryptographic keys130) and to enforce rules or controls (e.g., control 105) that areassociated with the content.

In one embodiment, secure processing application 100 comprises aninstance of the InterRights Point™ software or the Rights/System™software produced by InterTrust Technologies Corporation of 4750 PatrickHenry Drive, Santa Clara, Calif., although one of ordinary skill in theart will recognize that other suitable secure processing applicationsand/or digital rights management applications could be used instead. Forexample, without limitation, secure processing application 100 couldcomprise software and/or hardware that implements some or all of thevirtual distribution environment functionality and features described incommonly-assigned U.S. Pat. No. 5,892,900, entitled “Systems and Methodsfor Secure Transaction Management and Electronic Rights Protection,”issued Apr. 6, 1999 (“the '900 patent”), which is hereby incorporated byreference in its entirety. In one embodiment, secure processingapplication 100 is a relatively small footprint piece of software and/orhardware that is operable to perform the key management and revocationfunctionality set forth herein, but little if anything else. In apreferred embodiment, secure processing application 100 is constructedusing security and tamper resistance techniques such as those describedin the '900 patent to ensure that it functions in a relatively secureand reliable fashion.

As shown in FIG. 1, secure processing application 100 is used to accessprotected digital information 130 that is stored in a secure electroniccontainer 106 and/or in protected database 104. The secure electroniccontainer can take any suitable form. For example, secure electroniccontainer 106 might comprise a DigiBox® or DigiFile™ container producedby InterTrust Technologies Corporation, or might simply consist of anencrypted version of the protected digital information. In otherembodiments, other secure container formats—such as those described inthe '900 patent or available commercially—could be used. Similarly,protected database 104 may also be implemented in any suitable manner,including without limitation as described in the '900 patent and/orcommonly-assigned U.S. patent application Ser. No. 09/617,148, entitled“Trusted Storage Systems and Methods”, filed Jul. 17, 2000, which ishereby incorporated by reference.

As shown in FIG. 1, in response to a request 112 from application 103 toaccess content 108, secure processing application 100 extracts secretinformation—such as access key 130—from secure container 106 (e.g., bydecrypting the relevant portion of secure container 106) and/orprotected database 104, and forwards this information (or informationderived from, controlled by, or otherwise related to this information)to application 103. This secret information is needed by application 103to access protected content 108 and to render or make availableplaintext content 109. Alternatively, secure processing application 100may itself decrypt protected content 108, thus obviating the need toforward application 103 the information 130 needed to access thecontent. In either case, revocation of application 103's authorizationto process protected content 108 can be effectuated simply by revokingapplication 103's access to, or use of, the secret information 130controlled by secure processing application 100. For example, a control105 could be delivered to secure application 100 that indicates thatapplication 103 is not to be granted access (or certain types of access)to the secret information contained in secure container 106 or inprotected database 104. Similarly, another control could be delivered toindicate that access to the secret information should be restored.Additional information on exemplary implementations of controls such asthese can be found in the '900 patent, which was previously incorporatedby reference.

In some embodiments, the operation and security of some portion ofapplication 103 may be tested (e.g., before deployment) to ensurecompliance with operational and security requirements of the contentowner and/or system administrator. For example, the content owner orsystem administrator can establish the necessary criteria or minimalrequirements that application 103 must satisfy in order to render orprocess protected content 108. If it is subsequently discovered thatapplication 103 is no longer meeting these requirements, thenapplication 103's ability to access and/or manage content can berevoked, e.g., in the manner described above.

FIG. 2 illustrates an embodiment of a system related to the one shown inFIG. 1. As in FIG. 1, application 103 may comprise a DRM system orcontent rendering application that seeks to manage or render protectedcontent 108. As shown in FIG. 2, a control application 120 iscommunicatively coupled to both application 100 and application 103.Control application 120 may, for example, be created or supplied by atrusted third party (e.g., a party other than the providers ofapplication 100 and application 103), or may be provided by the providerof secure processing application 100. Control application 120 controlsaccess to database 107, which may be provided by the same party thatprovided the control application 120, or by a different party, and may,like control application 120, be located on the same system asapplication 100 and/or application 103, or on a different system.

As shown in FIG. 2, application 103 provides keyshare and/or otheridentification information 140 to control application 120. Thisinformation 140 is used by application 120 to obtain access toinformation stored in a database 107. A keyshare may, for example,simply comprise a portion of a decryption key. Control application 120is also supplied with a keyshare 134 (or an entire key) by secureprocessing application 100. As shown in FIG. 2, application 100 may haveretrieved keyshare (or key) 134 from a secure container 132 and may haveused a control 105 stored in its protected database 104 to decidewhether to supply keyshare 134 to control application 120. The use ofcontrols to govern the use of content is described in more detail in the'900 patent, which was previously incorporated herein by reference.Control application 120 uses keyshares 134 and 140—and possibly otherkeyshares maintained by control application 120 or obtained from othersources—to retrieve information 142 (such as a decryption key) needed toprovide access to content 108. Control application 120 supplies thisinformation to DRM application 103, which uses it to access protectedcontent 108. Having obtained access to content 108, DRM application 103governs it in accordance with any rules with which it is associated,and, if appropriate, may provide plaintext content 109 to a user orrendering application. In some embodiments, control application 120 maybe operable to decrypt protected content 108 itself, thus avoiding theneed to send the information needed to decrypt (or otherwise gain accessto) protected content 108 to application 100 or application 103.

The systems described above allow different DRM systems and applicationsto operate fairly independently (with respect to other key managementtechniques that may be available for protecting content), while alsoleveraging the hardware and/or software security features of the secureprocessing application 100. As noted above, the access key can be splitbetween the secure processing application 100 and the DRM application103, so that if application 103 has superior software and/or hardwaresecurity capabilities to that of application 100, the protection offeredby DRM application 103 would not be compromised if the security ofapplication 100 was compromised. As discussed above, shares of keyscould be split among applications, portable devices, local contentmanagement modules, and secure containers. For example, secure container132 could hold a share of a key necessary for the application 103 toestablish a secure channel with a portable device, a share of a key usedin the IEEE 1394 protocol, and so forth.

In addition, in some embodiments control application 120 can effectivelyserve as a mediator between two or more digital rights managementsystems (e.g., application 100 and 103), giving any digital rightsmanagement system the ability to supervise or control the operation ofthe others. Referring to FIG. 2, for example, certain content owners ordistributors may want the ability to revoke access to content 108 usingeither digital rights management system 100 or 103, thus obtaining somelevel of redundant protection in case either one of the rightsmanagement systems is cracked. This could be accomplished using thearrangement shown in FIG. 2, where either one of the rights managementsystem's ability to access protected content 108 and/or the informationcontained in trusted database 107 could be controlled by sendingappropriate commands or controls to the other rights management system.Thus, as shown in FIG. 2, protected content 108 could be packaged in theencoding format used by DRM application 103, thus giving DRM system 103the ability to manage the distribution and use of the content; however,this encoded content would itself be protected (e.g., further encrypted)such that DRM application 100 would be able to supervise the operationof application 103 and revoke access to content 108 if desired.Similarly, other pieces of content could be packaged in the encodingformat used by DRM application 100, thus giving DRM application 100 theability to manage the distribution and use of the content; however, thisencoded content could itself be protected such that DRM application 103would be able to supervise the operation of application 100, and revokeaccess to the content if desired. Moreover, if either DRM system wascompromised, the content owner could, if desired, prevent further accessto the content simply by sending an appropriate control to the DRMsystem that had not been compromised.

In some embodiments, key distribution and revocation schemes such asthose described in Naor et al. and the CPRM standard can be used toprovide control over local DRM systems or devices. See Naor et al.,“Revocation and Tracing Schemes for Stateless Receivers,” available athttp://citeseer.nj.nec.com/420701.html (February 2001). In suchembodiments, sets of keys (or keyshares) are distributed to local DRMsystems or devices (or classes of local DRM systems or devices), and, asdescribed above, those keys are used to access information needed by thelocal DRM system or device to access content or to perform certainfunctions. These keys can be revoked and/or updated using the mechanismsdescribed in Naor et al. and the CPRM standard, thus providing a way tocontrol/supervise the operation of the local DRM system or device. Forexample, if a finite geometry key distribution mechanism is used, andeach device or application is given a series (or distinguished subset)of keys, revocation can be accomplished by removing a series of keysfrom the key geometry.

An advantage of such an implementation is that a local DRM system (suchas application 103 in FIGS. 1 and 2) can be controlled without thenecessity of also installing a secure processing application such asapplication 100 on the local system, and/or without having tointeractively communicate with such an application 100 after application103 has been deployed. A disadvantage of such a technique is that it canbe relatively difficult to implement an efficient revocation mechanism,especially one that enables revocation of previously-packaged content.

Governance Via a Conformance Library and Credentials

In another embodiment, an application running on a host computer systemis governed by linking it to (or incorporating it with) a specialconformance library. The conformance library filters or mediates certainrequests from the governed application to the host computer system'snative platform services (e.g., file input/output and the like). Theconformance library invokes a supervisory application that determineswhether the governed application has been improperly modified andwhether it is authorized to perform the requested action. If thesupervisory application determines that the governed application has notbeen improperly modified and is authorized to perform the requestedaction, then the governed application's request is forwarded to theappropriate host system service, which fulfills the request just as itwould had the supervisory application not first intercepted it. Severalillustrative embodiments of the foregoing process are described below inconnection with FIGS. 3A, 3B, and 3C.

FIG. 3A illustrates the conventional manner by which an application 302accesses electronic content 304 on a host computer system. Application302 may, for example, comprise a digital rights management application,content viewer, or any other type of application that assists orcontributes to the use, rendering, distribution, or management ofdigital information. As shown in FIG. 3A, when application 302 wishes toaccess content 304, it typically makes a call, via an applicationprogramming interface (API) 306, to a library of functions andprocedures provided by the host system for performing the detailed,low-level operations involved in retrieving the electronic content fromthe host system's storage and providing it to the requestingapplication.

FIG. 3B shows how the conventional system of FIG. 3A can be modified toprovide governance over the operation of an application 320. As shown inFIG. 3B, when application 320 wishes to access a piece of electroniccontent 304, it makes a call to a modified version of the host system'sfile input/output API 312. Calls to the modified API are handled byconformance library 314, which is operable to route these calls to agovernance engine (also referred to as a supervisory application) 316which determines whether the application's access request should begranted or denied. If supervisory application 316 determines that therequest should be granted, it routes the request to the host system'sfile I/O library 308 via the host system's API 306. The host system thenperforms the necessary operations to retrieve the electronic content 304for application 320.

It will be appreciated that an application 302 that was initiallydesigned to operate in the manner shown in FIG. 3A need not undergosubstantial modification to operate in the manner shown in FIG. 3B. Forexample, application 302 can simply be modified to indicate that callsto the host system's file I/O library 308 should be handled, instead, byconformance library 314. This would typically involve a few relativelyminor changes to the application's header files, and not to the body ofthe application (e.g., the actual form of the calls would remainunchanged, the only change being to the identification of the librarythat handles those calls). Thus, in such an embodiment, modified fileI/O API 312 would be virtually identical in form to the host system'sfile I/O API 306. Alternatively, each occurrence in the application ofcertain file I/O calls could be modified to refer directly to acorresponding function in the conformance library 314, although thesemodified calls would preferably be similar in form to the original fileI/O calls (i.e., the modified file I/O API 312 would preferably besimilar to the host system's API 306). Thus, in a preferred embodimentthe application developer can integrate the supervisory application withthe governed application quite easily, with little or no modification tothe governed application, thus limiting the likelihood that bugs will beintroduced into the application, or that call-paths through the governedapplication will be missed and governance compromised. In addition, theconformance library will typically be easy to test since it ispreferably API-compatible with the standard platform interfaces.Application 320 need not be integrated in any other capacity with thesystem of governance engine 316.

FIG. 3C illustrates another embodiment of a system for governing anapplication in accordance with the present invention. Referring to FIG.3C, a governance application 360 is linked via a conformance library 351to a governed application 352. The conformance library 351 implementsinterfaces that that the governed application 352 must call, therebygoverning the file I/O calls (e.g., file system calls, the ability toload other code dynamically, other system calls such as Kernel32 orWin32 API calls, and the like) from the governed application 352. Theconformance library 351 effectively looks like a replacement set of filesystem I/O calls, and possibly a small set of additional calls (forexample, GetProcAddress and LoadLibrary on Windows).

A mediator/shim 354 re-implements the actual file I/O calls through afilter 355 where the governed calls are controlled by the conformancelibrary 351. The governance system effectively enforces the requirementthat the file I/O call go through the conformance library 351 first. Themediator/shim 354 of the conformance library 351 may incorporateadditional logic which, e.g., (a) allows it to verify or validate that alegitimate authorization certificate/conformance certificate has beengiven by the content owner, and (b) to force a credential check on theapplication 352 to ensure that it and/or the conformance library 351have not been modified.

In a preferred embodiment, the conformance library 351 makes calls togovernance engine 360. Governance engine 360 may, for example, be in theform of a commercial digital rights managements application, such asInterTrust's InterRights Point software or Rights/System software.Governance engine 360 may be installed on the same computer system asapplication 352, or may reside elsewhere, such as on a remote server.

The governance engine 360 checks the credential(s) 361 associated withthe application 352 and/or the conformance library 351. For example, ifthe credential 361 comprises a digitally-signed cryptographic hash orchecksum, the governance engine 360 preferably verifies the authenticityof the digital signature, then computes the corresponding hash orchecksum on the appropriate portions of the governed application 352and/or conformance library 351 to determine whether the governedapplication and/or library have been modified. If a strong, one-wayhashing algorithm such as SHA-1 is used to generate a hash of theapplication and/or conformance library (or selected portions thereof),then it will be computationally infeasible to modify the hashed portionswithout detection by the governance engine (i.e., the hash computed bythe governance engine of the modified application will not be the sameas the hash contained in the credential).

If the governance engine 360 determines that the application has notbeen modified, then the governance engine 360 checks the certificate 362associated with the application to determine whether the application isauthorized to perform the action that it is seeking to perform. In oneembodiment, the application's certificate 362 forms part of credential361. In other embodiments, the certificate may be maintainedindependently by governance engine 360, the association between thecertificate and application 352 being accomplished via credential 361(e.g., the cryptographic hash or checksum of the application serving toidentify the application to the governance engine as the possessor ofthe authorizations specified in the certificate (which might alsocontain the hash or checksum)).

The certificate 362 serves as a cross-reference to ensure that theapplication 352 is authorized by the content owner as a certified orcompliant application in conformance with desired characteristics. It isintended that the content owner will be provided with, or have accessto, sufficient tools for generating “authorization certificates” forapplications 352 that implement the conformance library 351. The contentowner may be responsible for establishing the appropriate criteria forthe issuance of the certificates (and for checking for compliancetherewith). In this regard, it will be appreciated that any suitabletechnique can be used to generate and utilize the conformancecredentials and certificates, including without limitation thecredentialing techniques described in the '900 patent, Menezes at pages321-481, U.S. Pat. No. 6,157,721, entitled “Systems and Methods UsingCryptography to Protect Secure Computing Environments,” issued Dec. 5,2000 (“the '721 patent”), U.S. patent application Ser. No. 09/628,692,entitled “Systems and Methods for Using Cryptography to Protect Secureand Insecure Computing Environments,” filed Jul. 28, 2000, U.S. PatentApplication No. 60/210,479, entitled “Rights Management Systems andMethods,” filed Jun. 9, 2000, U.S. patent application Ser. No.09/863,199, entitled “Trust Management Systems and Methods,” filed May21, 2001, each of which is hereby incorporated by reference in itsentirety, and U.S. patent application Ser. No. 09/879,743, entitled“Rights Management Systems and Methods,” filed Jun. 11, 2001, whichclaims benefit to Provisional Application No. 60/210,479, filed Jun. 9,2000.

In one embodiment, after the application vendor has implemented thelibrary 351 and received a certificate 362, it presents the applicationand certificate to the third-party governance service identified by thecontent owner. The third-party governance service generates a credential361 which wraps the certificate so that it cannot be tampered with(e.g., using a one-way cryptographic hash); the credential is stronglyauthenticated and bound to the application. The vendor receiveseverything back along with the credential. The application vendordistributes its product in the normal manner. In this embodiment,updates to the application may require re-credentialing. Applicationsthat use the library need not ship the governance engine, but onceenabled with the library, will only be able executecontent-owner-controlled functions in the presence of the governanceengine.

FIG. 4 illustrates a method for governing content rendering applicationsand digital rights management systems using the system shown in FIG. 3C.As shown in FIGS. 3C and 4, when a content rendering application ordigital rights management system 352 starts, it makes a call toinitialize a conformance library 351 (401). Conformance library 351opens a connection with a governance engine 360 (402) and forces acredential check (403). If credential 361 is bad (i.e., a “No” exit fromblock 404), the conformance library returns an initialization failure(405) that disables the application and returns a system error.Alternatively, other failure modes could be used, including, forexample, continuing operation but providing the user with a means ofobtaining a new credential.

Referring back to FIG. 4, if credential 361 is good (i.e., a “Yes” exitfrom block 404), application 352 checks certificate 362 to determinewhether the application is authorized by the content owner to accesscontent (406). If authorization is detected (i.e., a “Yes” exit fromblock 407), the conformance library 351 will pass subsequent API callsthrough to the host system's file I/O API, and the application 352 willrun normally (408). If authorization is not detected (i.e., a “No” exitfrom block 407), the application's calls will not be passed through tothe file system, and the application will thus be unable to perform thegoverned operations.

It will be appreciated that a number of variations can be made to theprocess shown in FIG. 4 without departing from the principles of thepresent invention. For example, while FIG. 4 shows a process fordetermining once, when an application is initiated, whether theapplication is authentic and is authorized to perform certain actions,it should be appreciated that alternatively, or in addition, theapplication's integrity and/or authorization could be checked by thesupervisory application each time the application seeks to perform oneof the governed operations, or at predefined intervals.

In a preferred embodiment, the conformance library 351 requiresgovernance to be affected by an enforceable set of interactions with thegovernance engine 360 using the application credentialing mechanism.However, unless the provider of the governance engine 360 certifies theapplication 352, the credential 361 imposes no other control over theoperation of the application 352 (and the application developer need notlearn anything more about the governance engine provider's system). Anapplication that incorporates this mechanism may pick up some additionalruntime characteristics, such as runtime anti-debugging, tamperresistance, and/or the like.

In one embodiment, the actual determination of whether a governedapplication has the right to render or use digital information is madeby functions implemented by the conformance library that validate thecontent owner's certificate. However, the governance interaction ofestablishing a valid session with the governance engine and checking thecredential is first performed in order to determine whether theconformance library should be allowed to access the certificate at all.If the credential is valid, the conformance library is allowed toretrieve the certificate, and if the certificate is valid, theconformance library allows the governed calls (e.g., file I/O calls) toproceed in the normal manner. The conformance library 351 thusimplements logic that: (a) checks for a credential issued by the contentowner or some other entity, and (b) implements non-subvertible linkageand calls to the underlying governance engine. Thus, in this embodiment,the provider of the governance engine effectively enables the managementof the governed application, but the policies and rules that affectwhether or not the application can actually render content or performother controlled operations are established by authentication of thecontent owner's certificate. Thus, content owners can establish athird-party governance engine that enables strong enforcement of thecontent owners' policies without imposing additional policies of thethird-party provider of the governance engine. Revocation can also behandled by using expiring credentials and/or certificates, and forcingupdates on a predefined, periodic basis—for example, quarterly, yearly,daily, or on a different time period or basis.

As indicated previously, in other embodiments the application'scertificate (or additional certificates associated therewith) may bemaintained and enforced by the governance engine itself, rather than theconformance library. This allows the content owner (and/or the providerof the governance engine) to dynamically revoke the certificates simplyby sending appropriate commands to the governance engine (e.g., sendinga new certificate or control that revokes the original certificate).

Although the foregoing invention has been described in some detail forpurposes of clarity, it will be apparent that certain changes andmodifications may be practiced within the scope of the appended claims.It should be noted that there are many alternative ways of implementingboth the processes and apparatuses of the present invention.Accordingly, the present embodiments are to be considered asillustrative and not restrictive, and the invention is not to be limitedto the details given herein, but may be modified within the scope andequivalents of the appended claims.

1-18. (canceled)
 19. A method of controlling access to electroniccontent by an application program running on a host computer system, themethod including: generating a request to access a piece of electroniccontent, the request being generated by the application program andcomprising, at least in part, a call to a conformance library running onthe host computer system; and in response to the call to the conformancelibrary, connecting the conformance library to a governance engine onthe host computer system, the governance engine being operable togovern, at least in part, the operation of the application program, thegovernance engine performing the following steps: (i) performing anintegrity check on the application program, the integrity check beingoperable to (a) detect improper modifications to at least part of theapplication program and (b) deny access to the piece of electroniccontent if an improper modification is detected; and (ii) performing anauthorization check, the authorization check being operable to (a)determine if the application program is authorized to access electroniccontent and (b) deny access to the piece of electronic content ifauthorization is not detected; and retrieving the piece of electroniccontent from a file system of the host computer system if permitted bythe governance engine.
 20. A method as in claim 19, wherein theapplication program comprises a content rendering application.
 21. Amethod as in claim 19, wherein the application program comprises adigital rights management program, the digital rights management programbeing operable to manage the use of the piece of electronic content inaccordance with one or more rules with which the piece of electroniccontent is associated.
 22. A method as in claim 19, wherein performingthe authorization check includes examining one or more digitalcertificates associated with the application program, the one or moredigital certificates specifying, at least in part, the nature of theapplication program's authorization to access electronic content.
 23. Amethod as in claim 22, wherein one or more of the digital certificatesis operable to expire at a predefined time, and wherein the applicationprogram's authorization to access electronic content expires when saidone or more digital certificates expire.
 24. A method as in claim 23,wherein the governance engine is operable to receive one or more newdigital certificates to replace one or more expired digitalcertificates, and wherein the application program's authorization toaccess electronic content is renewed when said one or more new digitalcertificates are received by the governance engine.
 25. A method as inclaim 19, wherein performing the integrity check includes generating acryptographic hash of at least part of the application program, andcomparing the generated cryptographic hash to a previously generatedcryptographic hash.
 26. A method of controlling access to electroniccontent, the method comprising: receiving, at a conformance libraryrunning on a computer system, a request from a governed applicationrunning on the computer system to access a piece of electronic content,wherein the conformance library implements one or more interfaces thatthe governed application calls to access the electronic content, andwherein the request to access the piece of electronic content comprisesat least a first call to at least a first interface of said one or moreinterfaces that the conformance library implements; connecting to asupervisory application, the supervisory application being operable tocheck a credential associated with the governed application, thesupervisory application being further operable to disable access to thepiece of electronic content by the governed application if thecredential check fails; and enabling access to the piece of electroniccontent by the governed application after completion of a successfulcredential check, wherein said enabling step includes making at least asecond call to at least a second interface, and wherein the secondinterface comprises a file input/output interface of the computer systemthat corresponds to said first interface implemented by the conformancelibrary.
 27. The method of claim 26, further comprising invoking thesupervisory application prior to the step of connecting to thesupervisory application.
 28. The method of claim 26, wherein thecredential check comprises an integrity check on the governedapplication, the integrity check being operable to (a) detect impropermodifications to at least part of the governed application and (b) denyaccess to the piece of electronic content if an improper modification isdetected.
 29. The method of claim 26, wherein the supervisoryapplication is further operable to perform an authorization check, theauthorization check being operable to (a) determine if the governedapplication is authorized to access the piece of electronic content and(b) deny access to the piece of electronic content if authorization isnot detected.
 30. A computer-readable storage medium storinginstructions that, when executed by a computer, cause the computer toperform steps comprising: receiving a request from a governedapplication running on the computer to access a piece of electroniccontent, wherein the request to access the piece of electronic contentcomprises at least a first call to at least a first interface;connecting to a supervisory application running on the computer, thesupervisory application being operable to check a credential associatedwith the governed application, the supervisory application being furtheroperable to disable access to the piece of electronic content by thegoverned application if the credential check fails; and enabling accessto the piece of electronic content by the governed application uponcompletion of a successful credential check, wherein said enablingincludes making at least a second call to at least a second interface,and wherein the second interface comprises a file input/output interfaceof the computer that corresponds to said first interface.
 31. The mediumof claim 30, further comprising instructions that, when executed by thecomputer, cause the computer to invoke the supervisory application priorto connecting to the supervisory application.
 32. The medium of claim30, wherein the credential check comprises an integrity check, theintegrity check being operable to (a) detect improper modifications toat least part of the governed application and (b) deny access to thepiece of electronic content if an improper modification is detected. 33.The medium of claim 30, further comprising instructions that, whenexecuted by the computer, cause the computer to perform an authorizationcheck, the authorization check being operable to (a) determine if thegoverned application is authorized to access the piece of electroniccontent, and (b) deny access to the piece of electronic content ifauthorization is not detected.